Hello, and thank you for your contribution! I think it's a good example to show the slack notifications in the example, but we should keep in mind that not everyone might have slack which could lead to problems when trying out the lifecycle toolkit.

Would you mind if you write some documentation (Tasks) on how to enable Slack notifications instead of adding this to the core of the examples?

how to enable Slack notifications instead of adding this to the core

@thschue Yes sure. I will update PR. Thanks for reviewing the PR

@thschue updated according to your suggestion, could you please check the PR. Thanks much for your time and support.

Would you like to move this to the docs (docs/tasks/...) ?

Would you like to move this to the docs (docs/tasks/...) ?

Thanks, working on it.

@thschue, Should I copy the entire readme under the docs/taks. We can name the task as Deploying-sample-app.

@thschue I think creating a new issue for adding a "Deploying sample app" section to the docs/task will be better. I'll write a guide for deploying and testing the sample app which can be added to the documentation site. Let me know your thoughts."

The current structure of the documents has some issues and these will be resolved in time. The section called "Tasks" is not well-structured -- we need to have a section called "Installation". Then I think we will have a "User Guide" or some such that discusses how to implement various features/capabilities into ones Keptn Application. In that User Guide, I envision a section about KeptnTaskDefinition that begins with a page like what is in the "Write Keptn Tasks" page, and then has other pages about specific features/functionality. One of these could be "Implementing a post-deployment Slack notification" and I suggest that you use this text to create that page. Although maybe it should be called just "Implement Slack notifications" because I think one would use the same method to implement Slack notifications in the pre-deployment phase and perhaps elsewhere.

For now, give that file a weight that puts it after the write-tasks file but before evaluate. If you don't know what I mean by "weight", check the contents of the CONTRIBUTING.md file for the docs that is currently in the PR I sent you. It's part of the metadata for each file. Many doc engines specify the files to be built and the order by using some sort of a list. Hugo instead builds everything that is there (unless it is explicitly excluded) and uses the "weight" parameter to control the order in which the files are displayed.

Hi @StackScribe, I am moving forward with your suggestion. Would appreciate if you could have a look at the PR.

Codecov Report

Merging #788 (95035f0) into main (b5c5801) will decrease coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #788      +/-   ##
==========================================
- Coverage   57.75%   57.69%   -0.06%     
==========================================
  Files          91       91              
  Lines        7243     7243              
==========================================
- Hits         4183     4179       -4     
- Misses       2891     2894       +3     
- Partials      169      170       +1     

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

Thanks for the contribution @sudiptob2
The pipeline fails but has nothing to do with these changes :)